Week 6, Day 2 — Compliance Policies & Conditional Access Device Compliance

Day 1 status check — hybrid join catch-up if needed

• Quick hands-up: how many students have WIN-CLIENT-01 showing AzureAdJoined = YES and DomainJoined = YES in dsregcmd? For any who don't — 5-minute targeted troubleshooting before the lecture (most common fix: reboot the client, or re-run gpupdate /force after verifying the GPO applied via gpresult /r)
• Ask: "Your device is now in Intune with Compliance state = Not evaluated. What does 'Not evaluated' actually mean — has the device been checked and found to have no issues, or has it not been checked at all?" — answer: not checked at all. No compliance policy has been assigned, so Intune has no rules to evaluate against. It's the same as no score on an exam that hasn't been given yet.
• Ask: "If CA001 says 'Require compliant device', and the device is Not evaluated — can the user sign into M365?" — answer: depends on CA policy configuration. By default, Not evaluated = treated as non-compliant. Frame this as the motivation for today: assign a real compliance policy so devices actually get evaluated.

Compliance policies — the rules, the states, and the CA connection

A compliance policy is a set of rules that devices must meet. Intune evaluates each enrolled device against its assigned compliance policy and reports a state — Compliant or Non-compliant. That state is then readable by Conditional Access.

The four compliance states

• What compliance policies check — Windows examples — minimum OS version (e.g. Windows 11 22H2 or later), BitLocker required, Microsoft Defender Antivirus required and up to date, password required with minimum length and complexity, Secure Boot required, Code Integrity required, firewall required. Each setting can be set as required or not configured (not checked).
• Non-compliance actions — what happens when a device is found non-compliant. Options: Mark device non-compliant immediately, send email to user, send push notification, retire the device (wipe corporate data), lock the device. The most common production setup: immediate non-compliant marking, email notification to user, grace period of 3–7 days before access is blocked, then retire after 30+ days of continued non-compliance.
• Device groups vs user groups — compliance policies are assigned to device groups (not user groups). This is different from Teams policies and CA policies which target users. A device group in Entra ID contains device objects. The most common setup: create an All Windows Devices dynamic device group (filter: deviceOSType = Windows) and assign all Windows compliance policies to it.
• The CA device compliance connection — this is the payoff of Weeks 2 and 6 coming together:

• Important nuance — the compliance check is asynchronous — CA does not query Intune in real time during sign-in. Instead, Entra ID caches the device's compliance state (updated each time the device checks in with Intune, typically every 8 hours). If a device becomes non-compliant between check-ins, the CA policy will still grant access until the next check-in updates the cached state. This is why device check-in frequency matters.

Lab 6-B: Windows compliance policy, device groups, intentional non-compliance, and CA wiring

Students create an Entra ID dynamic device group, build a Windows compliance policy with real security requirements, assign it, deliberately break WIN-CLIENT-02 to trigger non-compliance, observe and remediate, then update CA001 to require device compliance.

• Step 1 — Create an All Windows Devices dynamic group (10 min)
  Navigate to entra.microsoft.com → Groups → New group.
  · Group type: Security
  · Group name: SG — All Windows Devices
  · Membership type: Dynamic Device
  · Dynamic device membership rule: (device.deviceOSType -eq "Windows")
  Save. Wait 1–2 minutes for the rule to evaluate — then check members. WIN-CLIENT-01 (and WIN-CLIENT-02 if enrolled) should appear automatically.
• Step 2 — Create the Windows compliance policy (15 min)
  Navigate to intune.microsoft.com → Devices → Compliance → Create policy.
  Platform: Windows 10 and later. Name: LL — Windows Baseline Compliance.
  
  Configure the compliance settings — all seven categories:
  · Device Health: Require BitLocker = Require; Require Secure Boot = Require; Require Code Integrity = Require
  · Device Properties: Minimum OS version = 10.0.22000 (Windows 11 baseline)
  · System Security — Password: Require password = Require; Minimum password length = 8; Password complexity = Require digits and lowercase letters
  · System Security — Encryption: Encryption of data storage on device = Require
  · System Security — Device Security: Firewall = Require; Antivirus = Require; Antispyware = Require
  · Microsoft Defender: Microsoft Defender Antimalware = Require; Antimalware security intelligence up-to-date = Require
  · Actions for non-compliance: Mark device non-compliant = Immediately; Send email to end user = Day 1
  
  Assign to: SG — All Windows Devices. Save.
• Step 3 — Observe initial compliance state and break WIN-CLIENT-02 (15 min)
  Navigate to Intune → Devices → All devices. Click WIN-CLIENT-01. Wait for Compliance state to update from "Not evaluated" to either Compliant or Non-compliant (may take up to 15 minutes — trigger a manual check-in: Device → Sync in the Intune portal, or on the client: Settings → Accounts → Access work or school → [account] → Info → Sync).
  
  Now deliberately make WIN-CLIENT-02 non-compliant:
  · On WIN-CLIENT-02: open Windows Security → Virus & threat protection → Manage settings. Turn Real-time protection OFF.
  · Trigger a sync on WIN-CLIENT-02 from Intune portal: Devices → WIN-CLIENT-02 → Sync.
  · Observe the compliance state changing to Non-compliant in the Intune portal. Record how long it takes.
• Step 4 — Inspect non-compliance details and remediate (10 min)
  In Intune, click WIN-CLIENT-02 → Device compliance tab. Review which specific settings are marked as Not compliant. The Defender real-time protection should be flagged.
  
  On WIN-CLIENT-02: re-enable Defender Real-time protection. Sync from Intune. Observe the device returning to Compliant state. Record the time for the full non-compliant → remediated → compliant cycle.
• Step 5 — Add compliant device requirement to CA001 (15 min)
  Navigate to entra.microsoft.com → Protection → Conditional Access → Policies → CA001 — Require MFA for all users.
  
  Edit the policy. Under Access controls → Grant:
  · Keep: Require multifactor authentication
  · Add: Require device to be marked as compliant
  · Set: Require all the selected controls (both MFA AND compliant device)
  
  Save the policy. This means a user signing in from WIN-CLIENT-01 must both have MFA and have a compliant device. A user on a non-enrolled or non-compliant device is blocked even with valid MFA.
• Step 6 — Test the CA device compliance gate (optional but highly recommended)
  Temporarily make WIN-CLIENT-02 non-compliant again (disable Defender). Sync to confirm non-compliant state.
  
  On WIN-CLIENT-02, attempt to sign in to office.com or teams.microsoft.com as a Lakeview Logistics user. The CA policy should block access with a message indicating the device needs to be compliant.
  
  Re-enable Defender, sync, confirm compliant, then verify M365 access is restored. Record the exact error message shown when access was blocked.

⭐ Bonus: Custom compliance scripts and compliance reports

Reflection & preview

• Ask: "A Lakeview Logistics user is working from a coffee shop on their personal laptop that has never been enrolled in Intune. CA001 now requires a compliant device. Can they sign into M365?" — answer: no, because the device is not enrolled and therefore not evaluated → treated as non-compliant → blocked
• Ask: "A device checks in with Intune at 8am and is compliant. At 10am the user disables Defender. They try to access M365 at 10:15am. Are they blocked?" — answer: not immediately — the cached compliance state from the 8am check-in is still valid. They will be blocked after the next check-in (default ~8 hours) picks up the Defender change. This is the asynchronous nature of compliance evaluation.
• Ask: "You set non-compliance action = Mark non-compliant immediately. What's the difference between the device being marked non-compliant and the user actually losing M365 access?" — surface: two separate things. Non-compliant marking happens in Intune immediately. M365 access is blocked by CA only when CA evaluates the sign-in against the cached (updated) compliance state.
• Preview Day 3: compliance controls what devices are allowed to access M365. Configuration profiles control what those devices look like from the inside — settings, KFM, Windows Update. Day 3 implements the KFM design from Lab 4-D Bonus B as a real Intune configuration profile.